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Abstract 

XML can play several roles in a distributed object 
system^ In particular, data can be serialized in XML- 
based formats. XML-encoded data can be more self 
describing than data encoded in many more traditional 
ways, which facilitates the kind of decentralized protocol 
evolution seen in Internet-scale development: XML's 
explicit "tagging and bagging" helps keep extensions 
straight. However, today's common distributed object 
systems have type systems that are not flexible enough to 
describe such , data. We suggest a way to make more 
flexible data types; this improves distributed object 
systems in general, and is critical to realizing XML's full 
potential. This approach has: (I) typing judgements 
based on type structure instead of type identity, (2) 
extensible record types with optional fields, (3) coarse 
record types, for which extension is compatible with 
subtyping, and (4) non-ignorable fields in record values. 

1 Introduction 

The following figure shows six data objects and 
descriptions that illustrate various roles for data and data 
descriptions in distributed object systems. 
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Many distributed object systems (such as CORBA [1], 
COM [2 J, and Java RMI [3]) have an interface language, 
in which various data types can be defined. These 
systems then have standard mappings from the interface 
language to a serialized data representation "on the wire" 
and into various programming languages. The data 
architecture depicted above has the virtue that the 
interface data and types form a *Svasp waist" that can join 



various data representations on the left with various 
programming language presentations on the right without 
a multiplicative explosion of complexity. This 
architecture is more elaborate than the following common 
one: 



XML instance 



SAX/DOM 



application 

. . . but can be consistent "on the wire" by agreeing on the 
XML instances to use. 

As suggested by the first figure, XML can be involved 
in multiple ways: 

1. the serialized data representation can be based on 
XML; 

2. an interface data type might be mappable to an XML 
data type in some XML schema languages); and 

3. the interface language might be based on XML or an 
XML schema language! 

The interface data types and XML data types can be 
connected in various ways. They all take the vertical arcs 
as fixed, but vary on the treatment of the angled arcs. In 
the simplest treatment, the way interface data are encoded 
into XML is fixed. That is, there is a generic (i.e., 
independent of the particular interface at hand) set of tags 
for marking up data such as records, arrays, numbers, and 
so on. In a more sophisticated treatment, the tags are 
specific to individual interface data types, but the 
encoding technique is still fixed. In a very sophisticated 
treatment, it would be possible for the interface author to 
exercise some choices in the way the data are encoded 
into XML. In general, the mapping between the interface 
data types and the XML data types may not have full 
fidelity, so there may be a need for two independent 
documents or one combined document 

The first role is generating a lot of excitement, because 
it promises better support of decentralized evolution 
through XML's self-descriptive powers. However, the 
type system of the interface language must be unusually 
flexible in order for XML's promise for data 
representation to be realized. This papier illustrates the 
problem and shows how to make sufficiently flexible type 
systems. 

Protocols deployed on a wide scale (such as the 
Internet) evolve in a particularly challenging way. In 
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contrast with smaller deployments, the evolution of 
widely deployed protocols is not managed by a single 
engineering organization. Rather, many independent 
shops develop evolutionary changes to the protocol, and 
then incrementally deploy these changes into the existing 
system. Evolutionary changes may be either "optional**, 
offering some degree of forward/backward compatibility, 
or "mandatory", meaning both sides of a conversation 
must support the change. Incremental deployment of 
independent evolutionary changes poses interoperability 
problems, both singly and in combination. The 
incremental deployment of a single evolutionary change 
presents the challenge of not only enabling new clients to 
work with new servers but also (at least in the cases 
where that makes semantic sense) enabling old clients to* 
work with new servers and/or new clients to work with 
old servers. The kinds of data typing seen in existing 
distributed object systems such as CORBA, COM, and 
Java RMI have technicalities that make them unable to 
say much about data that follow an evolutionary pattern; 
an extended example appears in the next section. Worse 
yet, for popular and important protocols (such as the 
World Wide Web's HTTP [4, 5]) t at any given time there 
are several independently developed evolutionary 
changes in the process of being incrementally deployed. 
This presents a further interoperability challenge. In 
general, a given client and sever that wish to interact each 
support a different set of extensions, and it is desirable for 
their interaction to use the intersection of those sets. 
Using existing data type systems to do the necessary ad 
hoc negotiations makes for messy application code, and 
possibly additional latency; the example in the next 
section also illustrates these problems. 

this paper shows an approach to creating more 
flexible data types for use in application-level network 
interface definitions. Using these more flexible data and 
types, developers can usefully describe their data and the . 
degrees of forward/backward compatibility desired. 
These ideas could be applied in future versions of existing 
network interface definition languages. 

The flexible data types that we show how to create are 
useful in more architectural contexts than the one 
suggested by "network interface". In particular, this 
flexibility is valuable when the producer and consumer 
are separated by time or access control and thus unable to 
negotiate (which rules out certain alternative solutions). 
This flexibility is also valuable when there isn't a single 
consumer for a given datum, for which negotiation-based 
solutions are (at best) problematic. Common examples 
include event distribution systems and database systems. 

This paper is organized as follows. In section 2 we 
examine the subtyping-based technique for decentralized 
evolution and note that it doesn't scale well. In section 3 
we outline our approach to making data types more 



flexible. We conclude with some brief remarks on related 
arid future work in section 4. 

2 Evolution by sub typing 

Let us consider what happens if we try to use 
subtyping to facilitate protocol evolution. Suppose a 
system starts out using the following type for its 
distributed objects: 

01 = {rn: {a:A} -> {x:X} } 

(This example and the rest of the paper are worked in 
the context of a very simple type system. "Objects** 
appear as extensible records with procedure- valued fields. 
A procedure type's domain is a record type — rather than 
a list of parameters — and the range is too. No "self" 
parameter is needed.) 

An optional extension that adds an argument and a 
result makes a new type like this: 

02 -{ m: {a:A} -> {x:X}, 

n:.{a:A ) b:B}-^ {x:X,y:Y} } 
The new type 02 is a subtype of the original type 01; for 
this We write 
02<:,01 

Old and new servers and clients have the following 
types: 

oId_server: 01 
new_server: 02 
old_client: 01 ^ T 
riew_client: 02 -» T 
There are four possible ways to combine these servers 
and clients. 
, old_clnt(oid_srvr); //works 
new_clnt(new_srvr); //works 
old__clnt(new__srvr); //works too! 
new_clnt(old_srvr); //doesn't work I 
The last combination doesn't work because 
old_srvr doesn't have the type required by 
new__clnt. So we have to write clients in a more 
complicated style. Here's the new client in that style (in a 
Java-like syntax): 

T new client (01 server) 

{ 

if (server instanceof 02) 

~ (02) server 
else 

... server 

} 

In addition to the scaling problems to be seen below, 
this type introspection may require round trips between 
client , and server before useful work can be done. This 
adds latency that some other techniques do not have. 

Suppose an independent extension such as this: 



03 = { m: {a:A} -> {x:X|, 

. o: {a:A, c:C} ^ {x:X, z:Z) } 
When a developer wants to use both extensions, she 
might create a type like this: 

04 = { m: {a:A} ~> {x:X}, 

n: {a:A, b:B} -> {x:X, y:Y}, 
o: {a:A, c:C} -» {x:X, z:Z}, 
p: {a: A, b:B, c:C) -> {x:X, y:Y, z:Z} } 

... and hews what a client cognizant of that combination 

would have to do: 

T client (01 server) 

{ 

if (server instanceof 04) . 
(04) server 

else if (server instanceof 03) 
(03) server 

else if (server instanceof 02) 
... (02) server 

else 

... server 

} 

In general, a client or server that understands N 
extensions has source code of size 2 N , or even greater. In 
many current distributed object technologies (including 
CORBA, COM, and Java RMI), types have identities as 
well as structure. If another developer were to 
independently write down a type with the same structure 
as 04, it would still be a different type; this developer's 
clients and servers would not fully intemperate with 04 
clients and servers, because they would not recognize 
each other's combined types. To get full interoperability, 
the two developers would have to go to a global 
engineering body, such as the W3C, IETF, ISO, or ITU, 
for a single global declaration of the combination. This 
imposes a significant additional delay in both 
development and deployment projects, simply to satisfy 
certain technicalities of the object system. 

Mandatory extensions do not suffer the exponential 
blow-up of code complexity due to all the possible 
combinations, but they do still suffer (in current systems) 
from the problem of agreeing on the identity of each 
combination. For example, if both of the above 
extensions were "mandatory", their combination would 
create a type like 

04' =* { p: {a:A, b:B, c:C) -> {x:X, y:Y, z:Z} } 
. . * and the client code would also be simpler: 

T client (04' server) {...} 
But in systems where types have identities, there would 
still be a need for a global agreement on an identity for 
the04* structure. 

Evolvable data can be described using existing 



interface languages — just not very precisely. 
Specifically, the extensible data can be described as tree 
structured "property lists" (also called "association lists" 
or "attribute lists"). As this is close to XML's 
information set, it is unsurprising to see excitement about 
using XML for representing evolvable data. 

3 New solution 

To overcome the difficulties just explored, we use a 
more flexible data and type system. This system is 
distinctive in five ways. 

1 . Type relations are judged on structure, not identity. 

2. Record types are extensible. 

3. Each field of a record type has a "mode" flag that 
indicates whether the field must be present in 
corresponding record values. 

4. There are some unusually coarse types, to cover 
evolutionary changes that would not otherwise create 
subtypes. 

5. Each field of a record value is marked either 
Mgnorable* or 'non-ignorable*. 

We will examine each of these features in turn. In the 
course of doing so, we will note three relations among 
types: the familiar subtyping relation (<: $ ), the new 
extension relation (<: e ), and the new refinement relation 
(<: r ). Extension is for evolutionary changes that are co- 
variant at procedure types (as opposed to the usual contra- 
variance for subtyping). Refinement is the transitive 
closure of the union of subtyping and extension. 

As discussed above, we judge type relations based on 
structure rather than identity, so that developers do not 
need a global standardization body to produce 
interoperable clients and servers of combined extensions. 

We use extensible record types so that they can model 
"objects" and other evolvable data. 

The next distinctive feature is optional fields. These 
correspond to optional subelements in an XML element 
content model, to optional headers in HTTP, and so on. 
Using this feature, we can describe the first example 
extension like this (for succinctness, we suppose that the 
"optionaJiry flag" defaults to "non-optional" when not 
explicitly written): 

02 = {m: {a:A, b:optional;B} 

-> {x:X, y:optional:Y} ) 
An XML content model for an XML representation of 
m's request messages might be "A, B?" 

This can be formalized as follows. A general record 
type looks like this: 

{l^m,:^, ... l D :mn:T n } 
where each I; is a label (i.e., field name), rr\ is a Boolean 
indicating whether the field is optional, and T, is the type 
of the field. A general record value is also a set of triples: 
{li:igi:v 1 >..:l n :ig 0 :v nl ) 



where each 1* is a label, each ig* is an ignorable" bit (see 
below), and each v^ is a field's value. A given label may 
not appear twice in a given record type or record value. 

Every record type is implicitly extensible; a given 
record value (of the form above) has a given record type 
(of the form above) when: 

• for all 1 < i < n : nij v the record value has a field 
labelled 1;; and 

• whenever 1 : ig: v appears in the record value and l:m:T 
appears in the record type^ v has type T. 

While many other type systems allow construction of 
what users may think of as "optional types*' (e.g., 
"datatype OFoo * present of Foo | absent" in ML), by 
putting recognition of the concept of optionality into the 
type system we get additional flexibility. For example, a 
record value of the form "(a:v)" can have type "{a:A, 
b:optional:Foo}", whereas it can't have a type of the form 
"{a:A, b:OFoo}". 

The rules for subtyping and extension are as follows. 
Record type 

R2 = {hirnVT*!, ... Wm* n+ k-TVv} 
is a subtype of record type 

Rl = {l 1 :m I :T^...V.m 0 :T n } 
when 

■ TV<: a ti ■ forall 1 <i<n;and 
nii v -»m* i for all 1 < i < il 
the rule for extension is analogous: R2 <: e Rl when 
T'i<: e Ti forall 1 <i<n; and 
rrijV-.m\ for all 1 < i < ri. 
It is at procedure types that extension and subtyping 
differ: 

(T'-frU') <:,(T-»U) 
when 

(T<: s T')a(U'<:,U) 

but 

(T^U0<:<(T->U) 
when 

(r<: c T)A(lT<: c U) 
As usual, subtyping is reflexive and transitive; extension 
and refinement are too. 

Thus, the request record type of 02 m is both a 
subtype and an extension of the request type of 01 .m; the 
same is true of the response record types. As this is co- 
variant, 02.m's type (a procedure type) is an extension, 
but not a subtype, of 01.m's. Consequently, 02 is an 
extension, but not a subtype, of 01. 

Since extension does not necessarily imply subtyping, 
we would have a very awkward type system if we stopped 
here. A client of type "01 -> T" could not be applied to a 
server of type 021 To solve this problem, we introduce 
"coarse types". Each coarse type is associated with an 
"ordinary**, or fine, type; we write "[T]" for the coarse 
type associated with fine type T. A coarse type [T] is the 



(untagged) union of all the refinements of T. That is, 
every value of every type U that is a refinement of T is 
also a value of [T]. In terms of type relations, this means 
that whenever 

T'<: r T 
we also have 

,[T*]<: 8 [T]Ar<: 5 [T] 

In the example above, 02 is a refinement of 01, so 
01, 02, and [02] are all subtypes of [Oil, and thus a 
client of type [01]-»T is applicable to a server of type 
02. 

In effect, coarsening a type removes some information. 
For a coarse record type R = [{a: A, . . . }], what is known 
about its "a" field is only that it has the coarse type [A]. 
For a coarse procedure type [A— >B], what is known is 
only that the domain is some refinement of A and the 
range is some refinement of B: an invocation with a 
general A value (1 ) might fail due to a mismatch with the 
actual domain of the procedure value, and (2) might 
return a value that does not have type B. For example, if 
we constructed the following mandatory extension of 01 

02* - {m: {a:A, b:B} -> {x:X, y:Y} } 
we could statically pass the value (a:anA) to an 
invocation of the m method of an object of coarse type 
[01] — but the invocation would fail at runtime if the 
object had type 02\ 

The final distinctive feature, which supports 
"mandatory" extensions, is that each field of a record 
value is marked either as "ignorable" or as "non- 
ighorable". For example, in an XML encoding, we might 
suppose that each record field would be a distinct XML 
element and define a standard attribute (say, 
"xml ignorable") to carry the "ignorable" bit If the 
first extension above were mandatory and the second 
optional, we might find a request message like this: 

<04 .m.reque6t> 

<A xmlignorable=" false" >„.</A> 
<B xmlignorable- w f alse w >„.</B> 
<C xml ignorable^" true* >...</C> 

</04 .m. request > 
The "ignorable bit" need not explicitly appear in every 
element: it could have a default value, or it's value could 
be implied by the schema for the particular message at 
hand. 

When a record value field is marked ''non-ignorablc", 
this means it must ultimately be "understood" — to at 
least some degree — by the receiver. A complication is 
that we should allow the receiver to delegate partial or 
complete responsibility for this understanding (e.g., as a 
WWW proxy would), Thus, rather than build in a fixed 
policy for testing understanding (e.g., into the parameter 
passing mechanism), we make it the application's , 
responsibility to eventually test that it understood each 
piece of input, and this testing responsibility can be 



delegated along with the understanding responsibility. 
We suppose there is an understanding testing primitive 
available, which tests a record value (the input whose 
understanding requirements are to be tested) against a 
record type (listing all the fields understood) to see if 
every non-ignorable field in the value is mentioned in the 
type. For example, a server that implements the first 
extension directly, and delegates nothing, would test its 
input against 02; a proxy that delegates all understanding 
would not test any understanding at all. 

As an example of how non-ignorable fields can be 
used, consider how to extend the proxy-ignorant protocol 
of 01 with proxying functionality (as in the WWW). 
Req = {a:A, pi:pptional:ProxyInstructions} 
Proxylnstructions = {origin:[01]} 

P={m;Req-*{x:X} } 

A server of type P is willing to either serve a request 
directly (if no Proxylnstructions appear in it) or act as a 
proxy for some other server (pi.origin). A proxying- 
aware client can pass either an unextented request 
(a:false;anA> or an extended request (a:false:anA, 
pi:faJse:<origm:false:q)) to a server of type [Ol J. Without 
the "ignorable" bit mechanism, a client making a 
proxying request would have no assurance that the 
request will be properly interpreted: a plain old 01 server 
would simply ignore the unrecognized "pi" field and 
process the request itself. With the added mechanism, the 
client is assured that the server will return an error if it 
does not recognize the fact that it is being asked to proxy. 

Note that this example can correctly encompass the 
hop-by-hop vs. end-to-end distinction. Hop-by-hop 
extensions can be added to the Proxylnstructions, which 
the proxy removes from the record before forwarding; the 
end-to-end extensions can go anywhere else in the 
request. A similar structure could be established for the 
response record type. 

4 Related and future work 

Structural typing and extensible records are common 
in the literature of programming language design f6J. 
Extensible records are involved in several hard problems 
that do not appear here. One of those is type inference, 
which is clearly not relevant. Another is efficient 
compilation; the practical problem for an interface 
language is rather mapping into various programming 
languages of interest. Another hard problem is how to 
explain implementation inheritance in object-oriented 
languages; again, that is not important for interface 
languages. In fact, it has long been recognized that 
interface inheritance and implementation inheritance are 
two separate things [7]; this has even been realized to a 
degree in Java. 



The OMG has recently adopted a limited form of 
extensible records, known as "objects by value" or simply 
"Value types", into CORBA; the limitation is that only 
single inheritance is allowed. 

The marking of extension fields with a "non- 
ignorable" bit is widely known; for example, it has been 
suggested for HTTP [8], 

The W3C's XML Schema Working Group [9] is 
working on producing a new schema language for XML. 
However, they have not (as of this writing) adopted any 
requirement for an XML Schema to also be able to serve 
as, or contain, a data type declaration in a higher-level 
interface language, 

Several things remain to be done. One item of high 
importance is to work out good mappings into various 
programming languages of practical interest; another is to 
fully work this approach put in a fully fleshed-out type 
system. In particular, it would be good to actually 
integrate it into the type system(s) of CORBA, COM, 
and/or HTTP-NG [10]. 

Another important task is to incorporate ordering 
information among the fields in an extensible record. In 
so doing, we make this approach usable not only for sets 
of orthogonal extensions, but also for sets that 
semantically interfere to a degree that can be untangled 
by simply specifying an ordering for the extension 
usages. Experience with HTTP shows that this would be 
a useful enhancement. 

It would be interesting to try to formulate this paper's 
approach using the "mix-in style" of inheritance [11]. 
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